java 熔断机制

这几天在看Hystrix的一些实现，里面大量运用了rxjava的原理，将代码简化到了极致，对于有rxjava基础的同学，相信看懂Hystrix代码并不是一件难事。我这篇文章主要是针对Hystrix Command执行之后的一个数据流向以及熔断机制做了一个梳理和总结，后续还会出对于Hystrix组装command、超时机制、隔离机制等源代码实现进行一个梳理和总结。这篇文章权当做hystrix梳理的第一步，虽然感觉从代码执行顺序上这篇文章不应该是第一个，但是从这一块开始梳理我感觉可以更好的理解Hystrix中的消息流的一个概念(不得不感叹，有的人写代码就是再创造，而我写代码可能就是为了工作吧。。)

首先我们先了解一下Hystrix熔断的一个基本原理：

Hystrix熔断机制流程图(转自Spring MicroServices in Action)

当出现问题时，Hystrix会检查一个一定时长(图中为10s)的一个时间窗(window)，在这个时间窗内是否有足够多的请求，如果有足够多的请求，是否错误率已经达到阈值，如果达到则启动断路器熔断机制，这时再有请求过来就会直接到fallback路径。在断路器打开之后，会有一个sleep window(图中为5s)，每经过一个sleep window，当有请求过来的时候，断路器会放掉一个请求给remote 服务，让它去试探下游服务是否已经恢复，如果成功，断路器会恢复到正常状态，让后续请求重新请求到remote 服务，否则，保持熔断状态。

这里我们就会考虑，我们应该怎么去实现这样一个window机制呢？通过ScheduledExecutorService和并发List以及累加器？我确实没想到比较好的方法，当我看了Hystrix的文档和实现之后，恍然大悟。它通过一个叫 metrics.rollingStats.numBuckets的属性，标明我们的window需要被拆分到多少个bucket(桶)中，对于我们上图的例子10s的window，我们设置5个桶的话，每个桶就是2s的时长。我们针对每个桶统计桶内的请求的一个情况(成功or失败)，然后对于10s的一个时长window，我们只要组合连续的5个bucket就能得到一个window内的统计数据，就能做一个判断，当有新的bucket来的时候，我们在我们的短路器中只需要抛弃最老的bucket，把最新的bucket加进来，形成一个LinkedList，就能重新做统计了，这样也形成了一个滚动统计的计算模式。这样的样例很适合通过基于流和响应式的reactiveX框架来做，因此Hystrix也采用了RxJava来实现。

在了解了Hystrix熔断的原理之后，我们上一个流程图(跟上面这图简直没法比，丑的想哭)：

command执行完成后数据流向

这是我自己整理的一个流程图，途中黄色箭头方向为数据流向方向，其中椭圆框有包含关系是因为这几个类存在继承关系，即HealthCountsStream继承自BucketRollingCountersStream，而BucketRollingCounterStream继承自BucketCountersStream。这个图比较清晰的展现了在一个comma